No linked issue — please open a GitHub issue for this bug and add 'Closes #NNN' to the PR body.

The fix is thorough and addresses all three layers correctly:

1. loader.ts — the root cause fix. The ExtensionAPI setModel wrapper was silently dropping the options argument, rendering every downstream persist guard ineffective. The one-line fix is correct.

2. auto.ts — the two setModel calls (stopAuto model restore and dispatchHookUnit hook model) now pass { persist: false }. Correct.

3. agent-session.ts — _applyThinkingLevel now gates both appendThinkingLevelChange and setDefaultThinkingLevel behind the persist check. The structural test (appendIdx > persistGuardIdx) verifies the ordering is correct and will catch any future regression that moves the append call outside the guard.

The package-lock.json version bump from 2.56.0 to 2.63.0 appears unrelated to the fix. If this was an accidental rebase artifact, it should be reverted to avoid noise in the diff. If it is intentional, it should be called out in the PR description.

Everything else — the structural guard test in model-isolation.test.ts, the loader test, the thinking-level session history test — is exactly the right coverage for this kind of silent persistence bug.

Prior feedback fully addressed. LGTM.

• Linked issue added (Closes #4339). Done.
• package-lock.json version bump artifact is no longer present in the diff. Done.
• All three fix layers are correct (loader.ts options forwarding, auto.ts persist:false calls, agent-session.ts thinking-level guard).
• Regression tests cover all the important seams.
• Full CI is green (build, lint, integration-tests, windows-portability, all rtk-portability variants — all passing as of 2026-04-16).

Verdict: REQUEST_CHANGES | Severity: MAJOR

The three-layer fix correctly addresses the stated problem. However there is one real bug and one structural test weakness that need resolution before merge.

MAJOR — _emitSessionStateChanged("set_thinking_level") fires even on no-op persist:false paths

In the new _applyThinkingLevel, _emitSessionStateChanged("set_thinking_level") sits outside the if (options?.persist !== false) guard but still inside if (isChanging). When called with persist: false, the event fires and any subscribers (UI, telemetry) will observe a thinking-level-changed signal even though no durable change was made. Whether this is a regression depends on pre-existing behavior — but the intent of persist: false is "transient, leave no trace", and an emitted session-state event is a trace. This should either be gated behind the same persist check or explicitly documented as intentional.

MAJOR — structural test for auto.ts is bypassable with multiline calls

tests/model-isolation.test.ts uses:

const setModelCalls = autoSrc.match(/\.setModel\([^)]*\)/g) ?? [];

[^)]* does not span newlines, so any setModel call formatted across multiple lines:

await pi.setModel(
  match,
  { persist: false },
);

produces \.setModel( with no closing ) in the match, yielding an empty array or a truncated match that fails to include persist: false. The test would then silently pass (the call isn't matched) or spuriously fail. This is the enforcement guarantee for the entire PR — if it can be bypassed by a formatting change the guard is hollow.

Fix: use a multiline-aware regex or read the AST. At minimum, use /\.setModel\([\s\S]*?\)/g with care for nested parens.

MINOR — setThinkingLevel public method is now a thin wrapper with no independent tests

The public API contract (setThinkingLevel always persists) is implicit — it just calls _applyThinkingLevel(level) with no options, so options?.persist !== false is true. This is correct, but it's worth a single explicit test asserting that calling the public method writes to settingsManager. Currently the tests only probe source text structure, not runtime behavior.

What's correct:

• loader.ts options forwarding is minimal and obviously right.
• auto.ts call sites — both stopAuto and dispatchHookUnit — are correctly updated.
• appendThinkingLevelChange being inside the persist guard is the right fix for the session-resume re-persistence loop described in the PR.
• The comment on _applyModelChange's existing persist !== false guard for setDefaultModelAndProvider confirms this PR is consistent with the prior guard pattern.